The Evolution of an Object-orietented Compiler Framework

class creation Abstract classes are important in the creation of any general-purpose framework. Such classes are frequently created simply by factoring out the common behavior from several related or sibling classes. However, the creation process for abstractclasses are important in the creation of any general-purpose framework. Such classes are frequently created simply by factoring out the common behavior from several related or sibling classes. However, the creation process for abstract classes is often subjective and creative, being guided by domain knowledge, experience, and intuition about what constitutes good and bad domain abstractions. While TypedParser provided some guidance for such factoring in the front-end framework, the abstract classes created were based primarily on the expected behavior of scanners and parsers. Figure 3. The old and new Smalltalk compiler class hierarchies AN OBJECT-ORIENTED COMPILER FRAMEWORK 527 A common misconception about abstract classes is that they can be anticipated and designed top-down at the beginning of a project. Unfortunately, it is often hard to derive good abstractions from the narrow focus imposed by the context of a single project. Useful abstract classes are often discovered during the post-mortem of a prototype implementation or during the implementation of a similar application, as opposed to during the initial design process. Two goals of the new front-end classes were to make the compiler easier to understand and to make it easier to create new varieties of compilers through subclassing. We examined the existing front-end classes and identified which properties were general enough to be included in the more abstract front-end framework. It was decided that two abstract classes, AbstractScanner and AbstractParser, would be sufficient. AbstractScanner, abstracted from Scanner, is an abstract class that provides protocols (related sets of messages that can be sent to instances of a class) for basic source stream manipulation, scanning support, and error handling. Scanner was renamed SmalltalkScanner and retained specific Smalltalk token scanning protocol, the required public access protocol, and more specialized error handling. AbstractParser, abstracted from SmalltalkParser, has protocols for public access, basic token acquisition, and error handling support. AbstractParser has an instance variable class to provide a class as a context for compiling. Exactly how this variable is used is determined by subclasses. Encoder, an esoteric parse node class, is used by the Smalltalk compiler as a symbol table. One of the primary functions of Smalltalk encoders is to maintain a mapping from variable names to their corresponding parse tree leaf nodes. In this manner, all occurrences of a variable within a parse tree can be represented by a single parse tree node. Historically, this technique was used to minimize the space required by the leaf nodes of a parse tree. As a prelude to future redesign and reimplementation of encoder functionality, we chose to represent the ‘encoder concept’ abstractly in the AbstractParser class, as opposed to being hard-coded into the parser. A particular class of encoder may be either created and initialized, by overriding the method stub initEncoder in a concrete subclass, or passed in as an argument with the source code.Parser, abstracted from SmalltalkParser, has protocols for public access, basic token acquisition, and error handling support. AbstractParser has an instance variable class to provide a class as a context for compiling. Exactly how this variable is used is determined by subclasses. Encoder, an esoteric parse node class, is used by the Smalltalk compiler as a symbol table. One of the primary functions of Smalltalk encoders is to maintain a mapping from variable names to their corresponding parse tree leaf nodes. In this manner, all occurrences of a variable within a parse tree can be represented by a single parse tree node. Historically, this technique was used to minimize the space required by the leaf nodes of a parse tree. As a prelude to future redesign and reimplementation of encoder functionality, we chose to represent the ‘encoder concept’ abstractly in the AbstractParser class, as opposed to being hard-coded into the parser. A particular class of encoder may be either created and initialized, by overriding the method stub initEncoder in a concrete subclass, or passed in as an argument with the source code. SmalltalkParser, a concrete subclass of AbstractParser, provides Smalltalk-specific parsing expressions, specialized error handling facilities, and miscellaneous public access protocols as required by the rest of the system. This functionality was formerly implemented in Compiler. Responsibility migration An instance of class Compiler accepts as input either a string or a ReadStream. The input is tested and converted into a ReadStream, if necessary, before passing it to the scanner/parser. This function was delegated to AbstractScanner, making scanners completely responsible for handling the input source. This refactoring involves the movement of methods from one class to another. It may also be characterized as the migration of a responsibility from one class to another. 7 AbstractParser has an instance variable scanner to access its associated scanner. In this case, the responsibility has migrated from an object into one of its components. Scanner had another subclass, ChangeScanner, which also had to be reimplemented. ChangeScanner, now a subclass of SmalltalkScanner, is used to convert